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REMARKS 

Claims 1-14, 16-32 and 34-45 are now pending in the case. Claim 15 was 
previously canceled. 



The Examiner's position regarding the IDS filed on 23 February 2009 is not 
understood and reconsideration is requested. Although the undersigned attorney did 
not mark the box indicating that the fee under 37 CFR 1 .1 7(p) was being submitted, a 
review of the file shows that the fee was, in fact, paid. Accordingly, the applicant is not 
required to make a certification statement and the Examiner is not operating within the 
scope of Patent Office Rules in not considering the IDS. 



Without presenting new matter, the applicant has amended claims 31 and 34 to 
recite the claims in a proper system claim format. Further, claim 31 is amended to 
incorporate the limitations of claim 33, which is then canceled. To assist the Examiner, a 
clean copy of the amended claims is presented: 

31. A receipting system for use in a purchasing transaction, the purchasing 
transaction having an associated identifier including identity information for a mobile 
device, the system comprising: 

i) an input device that receives transaction information; 

ii) a receipt generator device that generates a receipt for a notified payment; 

iii) a data store that stores network addresses and the associated purchasing 
transaction identifiers, the data store configured to store one or more sets of user- 
specific data for use in authorising transactions; 

iv) a user data maintenance computer program, operably stored on a 
processor accessible to the data store, for storing and updating user data in the data 
store, the network addresses being stored therein as user-specific data; and 

v) an interface device, connected to a network, that transmits the receipt 
generated for the purchasing transaction to the associated network address. 



Information Disclosure Statement 



Claim amendments 
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34. A payment system for use in user transactions, each transaction giving rise to a 
price list for goods or services covered by the transaction, wherein each user has at 
least one associated identifier including identity information for a mobile device of said 
user, the payment system comprising: 

an input device that receives identifiers; 

a data store for storing user specific data in association with at least one of the 
received identifiers; and 

a price list computer program, operably stored on a processor accessible to the 
data store, for processing a price list arising from a transaction, by applying user 
specific data from the data store, the user specific data being associated with an 
identifier received in relation to said transaction. 

Claims 36 and 37 are also amended to tie the method to a particular machine or 
apparatus, to overcome the Examiner's rejection of these claims as being directed to 
non-statutory subject matter, using In re Bilski as authority. No new matter is presented 
in making these amendments. 

Claim rejections - 35 USC §1 01 

The Examiner has made new rejections of claims 31-37 as being directed to non- 
statutory subject matter. Of these claims, claims 31 , 32, 34 and 35 are system claims 
and claims 36 and 37 are method claims, with claim 33 now being canceled. 

These rejections are addressed immediately above in association with the claim 
amendments. 

Claim rejections - 35 USC §102 

Applicant notes that the Examiner's rejection of claims 14-25, 34 and 36-37 
under 35 U.S.C. § 102(b) as being anticipated published US application 2002/0181710 
to Adam et al. ("Adam 710") are not repeated and are deemed to be overcome. 

The Examiner has now made a new rejection of claim 36 as anticipated under 35 
USC 102(e) by US Pat 7,239,226 to Berardi ("Berardi '226"). Applicant respectfully 
traverses. 
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In making this rejection, the Examiner states that Berardi '226 discloses the 
elements of "using the identifier to locate a set of one or more authorisation codes for 
payment systems", and "authorizing the transaction information with a payment system 
by use of an authorization code from said set" at Col. 18, lines 39-52 and lines 51-54. 

Applicant respectfully asserts that this is incorrect. Applicant asserts that the 
cited text in Berardi '226 discloses that additional or secondary verification may be 
provided by user input of a PIN. Then, lines 29 to 37 of Berardi '226 explain that the 
PIN input by the user is checked against a corroborating PIN stored locally or at a 
payment authorization centre. This is particularly noted at lines 32 to 35, which state: 
"The corroborating PIN may be stored locally (e.g., on the fob 102, or on the RFID 
reader 1 04) or may be stored on a database (not shown) at the payment authorization 
center" (emphasis added). Lines 38 to 44 disclose how the user PIN can be input using 
different keypad arrangements. Lines 44 to 52 disclose that the verification PIN input by 
the user can be compared to the corroborating PIN stored at the RFID reader or at the 
payment authorization center. At lines 45 to 50, Berardi '226 states that "the RFID 
reader 104 may seek to match the PIN... Alternatively, the verification PIN may be 
provided to a payment authorization centre" (emphasis added). 

From this, applicant concludes that Berardi '226 teaches only that a user input 
PIN can be compared to a stored corroborating PIN, either locally at the point of sale or 
at a remote payment authorization centre, and does not meet the express limitations of 
claim 36. 

Berardi '226 lacks any teaching or suggestion that a user input PIN (or other 
identifier) could be used to locate a set of one or more authorization codes and that an 
authorization code from said set could then be used for authorizing the transaction 
information, as required by claim 36. In particular, to use the Berardi '226 terminology, 
there is no teaching or suggestion that the user input PIN could be used to locate a 
stored corroborating PIN and that this located corroborating PIN could then be used for 
authorizing the transaction at the payment authorization center. 

In summary, Berardi '226 teaches only a one stage process where identify 
information (a user input PIN) is used directly to authorize a transaction, either at the 
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point of sale or at a remote payment authorization center. But claim 36 requires a two 
stage process, not met by Berardi '226, where an identifier is used to locate a set of one 
or more authorization codes and then an authorization code from said set is used to 
authorize transaction information. 

Accordingly, even if the stored corroborating PIN of Berardi '226 were to be 
regarded as being "a set of one... authorization codes" according to claim 36, and 
comparing a user input PIN to a stored corroborating PIN according to Berardi '226 
were to be regarded as "using the identifier to locate a set of one... authorization codes" 
according to claim 36, Berardi '226 would still not teach or suggest the two stage 
process of claim 36 of using an identifier to locate a set of one or more authorization 
codes for payment systems, and then authorizing the transaction information by use of 
an authorization code from said set. 

Thus, claim 36 is not disclosed by Berardi '226 and should be allowed. 

Claim rejections - 35 USC §103 

Applicant notes that rejections of claims 1-13, 26-30, 35 and 38-45 as obvious 
over a combination of Adam 710 with at least one additional piece of art have not been 
repeated and are deemed to be overcome. A rejection of claims 31-33 as obvious over 
a combination of Adam 710 with published US application 2003/0141361 to Nguyen 
("Nguyen '361 ") is made for the first time. 

The Examiner has made several obviousness rejections that start with Berardi 
'226 as the primary reference. Applicant respectfully traverses all of these rejections. 

As an initial observation, applicant directs the Examiner's attention to the number 
of references required to make some of the obviousness rejections. While KSR v 
Teleflex certainly does not limit the number of references that can be combined in 
making a rejection, applicant would suggest that KSR does require that the overall 
combination must be recognizable to one of ordinary skill as providing a predictable 
result. As in any combinatorial matter, introducing a third or a fourth variable, with the 
opportunity for confounded results, greatly reduces predictability. The European 
standard for obviousness, for example, suggests that the need to use a third or fourth 
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reference should be considered by the examiner as evidence that the claimed subject 
matter is not obvious. 

Berardi '226, Adam '710, Campisano '447 and Shore '662 

The first rejection is of claims 1-7, 9-12 and 32-43, which are considered obvious 
over Berardi '226 in view of Adam 710, Campisano '447 (as cited in the prior Office 
Action) and Shore '662 (also cited in the prior Office Action. Of course, the cancellation 
of claim 33 moots the rejection, as least as far as that claim is concerned. 

The Examiner suggests that Berardi '226 teaches everything in claim 1 except for 
"at least one server device for providing data and/or processes to support a transaction 
using the at least one client device, said transaction including verification of 
authorisation data" and "wherein the at least one server device is provided with a user 
data store adapted to store one or more sets of user-specific data for use in authorising 
transactions", which are taught by Adam '710, the feature of "said at least one server 
device being adapted to store a second part of the authorisation data comprising 
financial data relating to a user of the mobile device in association with said first part of 
the authorisation data and the mobile device identity information and, in response to 
receiving said first part of the authorisation data and the mobile device identity data, to 
verify said authorisation data and to retrieve said second part of the authorisation data 
comprising the user's financial data to complete a transaction" which is taught by Adam 
710 in view of Campisano '447, and the feature "wherein the at least one server device 
is provided with a user data maintenance process for storing and updating user data in 
the user data store", which is taught by Shore '662. 

Applicant considers this objection to be an improper "mosaic" type argument that 
the different features of the claim can be separately found in different ones of a plurality 
of documents, in this case that different features of claim 1 can be separately found in 
four different documents. The mere identification of separate disclosures of the different 
features of the claim in different documents does not show that "the subject matter as a 
whole would have been obvious" unless it can be explained with "articulated reasoning" 
why the skilled person would be motivated in an obvious manner to select the different 
features of the claim from the different documents and then to combine them to arrive at 
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the subject matter of the claim, with the combined results operating in a predictable 
manner. 

Further, applicant does not accept the Examiner's analysis of the prior art in this 
rejection as being correct. In particular, it is not accepted that the feature of "said at 
least one server device being adapted to store a second part of the authorisation data 
comprising financial data relating to a user of the mobile device in association with said 
first part of the authorisation data and the mobile device identity information and, in 
response to receiving said first part of the authorisation data and the mobile device 
identity data, to verify said authorisation data and to retrieve said second part of the 
authorisation data comprising the user's financial data to complete a transaction", is 
taught by Adam 710 in view of Campisano '447. 

Adam 710, and in particular the referenced paragraphs [0028], [0039], [0128], 
[0129] and [0168] thereof, teaches a server storing financial data associated with a 
customer identity. See paragraphs [0039], [0128] and [0129]. The server is arranged to 
receive from a point of service device a customer ID, a merchant ID and transaction 
details. See paragraph [01 68]. The server also uses these to verify and authorize the 
transaction. 

However, even if the customer ID of Adam 710 were to be regarded as 
corresponding to a first part of authorisation data according to claim 1 , Adam 710 still 
fails to teach a server "being adapted to store a second part of the authorisation data 
comprising financial data relating to a user of the mobile device in association with said 
first part of the authorisation data and the mobile device identity information" and "in 
response to receiving said first part of the authorisation data and the mobile device 
identity data" proceeding to "verify said authorisation data and to retrieve said second 
part of the authorisation data comprising the user's financial data to complete a 
transaction" according to claim 1 . Adam 710 lacks any teaching of a server "being 
adapted to store a second part of the authorisation data... in association with said first 
part of the authorisation data and the mobile device identity information" or "receiving 
said first part of the authorisation data and the mobile device identity data" at all. In 
particular, the referenced paragraph [0168] of Adam 710 teaches only "a first data 
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communication message 57 containing the customer's ID, the merchant's ID (also 
previously assigned to him by the administrator of the system), and the sum to be paid 
(the "transaction details"), is transmitted to the local CSC 2 (53)". 

Although Adam 710, paragraph [0168], teaches that the POS can receive the 
customer identification details or his mobile phone identification details, these are taught 
only as alternatives, and there is no teaching that both of the customer identification 
details and the mobile phone identification details should be received by the POS. 
Further, in Adam 710, regardless of which of these alternative identification details is 
received by the POS, the POS sends only the customer ID to the CSC. See paragraph 
[0168] : "Once POS 52 has received the customer's (or his mobile phone) identification 
details... a first data communication message 57 containing the customer's ID... is 
transmitted to the local CSC 2 (53)" (emphasis added). 

The discussion in paragraphs [0123] to [0125] and from paragraph [0168] make it 
clear that Adam 710 teaches only that phone identification details can be used to 
identify the customer to the POS device and not that they can be used for any other 
purpose. Adam 71 0 does not teach or suggest that the identity of the mobile phone 
itself, as opposed to the identity of the customer, should be sent to the CSC server, and 
does not identify any purpose for doing this. Further, since, as explained above, Adam 
710 does not teach a server "being adapted to store a second part of the authorisation 
data... in association with said first part of the authorisation data and the mobile device 
identity information", the server would not be able in any event to take any further action 
after receiving both the customer ID and the mobile phone ID beyond the action it takes 
in response to receiving the customer ID alone. 

The examiner has identified the disclosure of Adam 710 in view of Campisano 
'447 as relevant. However, even if the teaching of Campisano '447 that a user home 
telephone number can be used as a user identifier and that a user can select multiple 
PINs each corresponding to different credit cards is taken into account, the Examiner 
does not indicate why this would suggest to the skilled person that the teaching of Adam 
71 0 that a customer ID should be sent to a server should be extended to, or understood 
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as, the feature of claim 1 of "receiving said first part of the authorisation data and the 
mobile device identity data". 

Campisano '447, at column 2 lines 22 to 24, 32 to 34 and 42 to 43, teaches a 
payment system in which a user inputs their home phone number and a PIN in order to 
make a payment. See in particular Campisano '447, column 2 lines 22 and 23 "enter 
the cardmember's ten-digit home telephone number and PIN". This home telephone 
number is used to identify the user in place of a credit card number. Even when a 
telephone order is placed, there is no requirement that the home telephone number 
given is the number from which the user is calling. See column 2, lines 1 6 to 1 9 "Any 
telephone can be considered a point of purchase location since it is possible to 
telephone... and place a credit card order over the phone. 

Accordingly, the skilled person aware of both Adam 710 and Campisano '447 
could understand that the customer ID sent to the server in Adam '710 could be the 
customer's home phone number, as taught in Campisano '447. However, there is 
nothing in the combined teachings which would lead the skilled person to consider 
changing the teaching of Adam '710 of a server storing financial data associated with a 
customer identity, the server being arranged to receive from a point of service device a 
customer ID (which, according to Campisano '447, could be a customer home phone 
number), a merchant ID and transaction details and to use these to verify and authorize 
the transaction, to add the features of claim 1 of the server also storing mobile device 
identity information and responding to receiving both a first part of authorisation data 
and mobile device identity data. 

Thus, even if Adam '710 is read in view of Campisano '447, this would not teach 
the skilled person the feature of a server "being adapted to store a second part of the 
authorisation data comprising financial data relating to a user of the mobile device in 
association with said first part of the authorisation data and the mobile device identity 
information " and "in response to receiving said first part of the authorisation data and 
the mobile device identity data " proceeding to "verify said authorisation data and to 
retrieve said second part of the authorisation data comprising the user's financial data to 
complete a transaction" according to claim 1 . 
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The Examiner states that "it would have been obvious to one of ordinary skill in 
the art at the time of the invention to expand the apparatus of Berardi et al. to include 
the CSC to administer accounts of merchants and customers as taught by Adam et al. 
and cross-linking of a card holders phone number to the credit card number and 
providing the customer with a corresponding PIN". As explained above, even if one of 
ordinary skill in the art were to do this, the combination would only allow them to use a 
card holder's home phone number as a customer identifier, as taught by Campisano 
'447. Nothing in the combined teachings would lead one of ordinary skill in the art to 
predictably replicate the features of a server storing or responding to a first part of 
authorisation data and mobile device identity information according to claim 1 . 

Thus, contrary to the Examiner's unsupported assertion, this feature of claim 1 
cannot be arrived at by combining the teaching of Berardi '226, Adam 710 and 
Campisano '447. Accordingly, it is respectfully submitted that claim 1 is not obvious and 
its proper dependent claims 2-7, 9-12 and 38-43 are also allowable as proper 
dependent claims. 

Berardi '226, Adam '710, Campisano '447, Shore '662 and Nguyen '361 

The Examiner has rejected claim 8 by extending the rejection of claim 7 under 
the combination of Berardi '226, Adam '710, Campisano '447, Shore '662 discussed 
above to include the feature "wherein the user-specific data includes a public network 
address for at least one use and the receipt generator is adapted to transmit a 
transaction receipt to said public network address." The Examiner again makes 
unsupported conclusory statements as to what would have been obvious at the time of 
the invention to one of ordinary skill, ignoring the obvious problems of requiring five 
separate patent teachings to predictably interact. 

Berardi '226, Adam '710, Campisano '447, Shore '662 and Grunbok, Jr '603 

The Examiner has rejected claim 13 by extending the rejection of claim 1 1 under 
the combination of Berardi '226, Adam '710, Campisano '447 and Shore '662 discussed 
above to include the feature "wherein the at least one server device is provided with a 
scanning process for scanning through the ordered list until a sufficient balance is found 
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to complete the transaction." The Examiner again makes unsupported conclusory 
statements as to what would have been obvious at the time of the invention to one of 
ordinary skill, ignoring the obvious problems of requiring five separate patent teachings 
to predictably interact. 

Berardi '226, Adam '710, Campisano '447, Shore '662 and Sohaei '308 

The Examiner has rejected claims 44 and 45 by extending the rejection of claim 
40 under the combination of Berardi '226, Adam 710, Campisano '447 and Shore '662 
discussed above to include the features recited in claims 44 and 45. The Examiner 
again makes unsupported conclusory statements as to what would have been obvious 
at the time of the invention to one of ordinary skill, ignoring the obvious problems of 
requiring five separate patent teachings to predictably interact. 



The Examiner has rejected claims 14, 16-23 and 25 as obvious over Berardi 
'226, in view of Adam '710 and Campisano '447. 

The examiner suggests that Berardi '226 teaches the features of claim 14 with 
the exception of the features "at least one server device for providing data and/or 
processes to support a transaction using the at least one client device, said transaction 
including verification of authorisation data", which is taught by Adam 710, and the 
feature of "wherein the at least one server device is adapted to store said mobile device 
identity information and said authorisation data including a second part of the 
authorisation data comprising financial data relating to a user of the mobile device and, 
in response to receiving said first part of the authorisation data and the mobile device 
identity information, to verify said authorisation data and to retrieve said second part of 
the authorisation data comprising the user's financial data to complete a transaction" 
which is taught by Adam 710 in view of Campisano '447. 

This rejection is similar to the improper "mosaic" type argument used against 
independent claim 1 above. In this case, the Examiner asserts that the features of claim 
14 can be separately found in three different documents. Again, it is respectfully 
submitted that the mere identification of separate disclosures of the different features of 



Berardi '226, Adam '710 and Campisano '447 
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the claim in different documents does not show that "the subject matter as a whole 
would have been obvious" unless it can be explained why the skilled person would be 
motivated in an obvious manner to select the different features of the claim from the 
different documents and then to combine them to predictably provide an operative 
solution to the problem. 

Further, the Examiner's analysis of the prior art is not accepted by the Applicant. 
In particular, it is not accepted that the feature of "the at least one server device is 
adapted to store said mobile device identity information and said authorisation data 
including a second part of the authorisation data comprising financial data relating to a 
user of the mobile device and, in response to receiving said first part of the authorisation 
data and the mobile device identity information, to verify said authorisation data and to 
retrieve said second part of the authorisation data comprising the user's financial data to 
complete a transaction", is taught by Adam 710 in view of Campisano '447. 

Adam 710, and in particular the referenced paragraphs [0028], [0039], [0128], 
[0129] and [0168], teaches a server storing financial data associated with a customer 
identity, see paragraphs [0039], [0128] and [0129], the server being arranged to receive 
from a point of service device a customer ID, a merchant ID and transaction details, see 
paragraph [0168], and to use these to verify and authorize the transaction. 

However, even if the customer ID of Adam 710 were to be regarded as 
corresponding to a first part of authorisation data according to claim 1 , there is still no 
teaching therein of a server "adapted to store said mobile device identity information 
and said authorization data including a second part of the authorisation data comprising 
financial data relating to a user of the mobile device" and "in response to receiving said 
first part of the authorisation data and the mobile device identity data" proceeding to 
"verify said authorisation data and to retrieve said second part of the authorisation data 
comprising the user's financial data to complete a transaction" according to claim 14. In 
fact, there is no teaching in Adam of a server "adapted to store said mobile device 
identity information and said authorization data including a second part of the 
authorisation data" or "receiving said first part of the authorisation data and the mobile 
device identity data" at all. In particular, the referenced paragraph [0168] of Adam 710 
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teaches only "a first data communication message 57 containing the customer's ID, the 
merchant's ID (also previously assigned to him by the administrator of the system), and 
the sum to be paid (the "transaction details"), is transmitted to the local CSC 2 (53). 
Although paragraph [0168] of Adam 710 teaches that the POS can receive the 
customer's identification details or the customer mobile phone identification details as 
alternatives, there is no teaching therein that the customer mobile phone identification 
details should be sent to the CSC. Adam 710 teaches that, regardless of which of the 
alternatives of the customer's identification details or the customer mobile phone 
identification details is received by the POS, the POS sends only the customer ID to the 
CSC. See Adam 710, paragraph [0168] "Once POS 52 has received the customer's (or 
his mobile phone) identification details... a first data communication message 57 
containing the customer's ID... is transmitted to the local CSC 2 (53)" (emphasis 
added). 

It is clear from the discussion in paragraphs [0123] to [0125] of Adam 710 and 
from paragraph [0168] that the phone identification details are used only to identify the 
customer to the POS device and not for any other purpose. The teaching of Adam 710 
does not teach or suggest that the identity of the mobile phone itself, as opposed to the 
identity of the customer, should be sent to the CSC server, and does not identify any 
purpose for doing this. Further, since, as explained above, Adam 710 does not teach a 
server "adapted to store said mobile device identity information and said authorization 
data including a second part of the authorisation data", the CSC server of Adam 710 
would not be able to take any action in response to receiving the mobile phone ID. 

The examiner has identified the disclosure of Adam 710 in view of Campisano 
'447 as relevant. However, even if the teaching of Campisano '447 that a user home 
telephone number can be used as a user identifier and that a user can select multiple 
PINs each corresponding to different credit cards is taken into account this would not 
suggest in any way to the skilled person that the teaching of Adam 710 that a customer 
ID should be sent to a server should be extended to, or understood as, the feature of 
claim 1 of "receiving said first part of the authorisation data and the mobile device 
identity data". 
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Campisano '447, column 2 lines 22 to 24, 32 to 34 and 42 to 43, teaches a 
payment system in which a user inputs their home phone number and a PIN in order to 
make a payment, see in particular, column 2 lines 22 and 23 "enter the cardmember's 
ten-digit home telephone number and PIN". This home telephone number is used in 
Campisano '447 to identify the user in place of a credit card number, and even when a 
telephone order is placed, Campisano '447 does not require that the home telephone 
number given is the the number that the user is calling from, see column 2, lines 16 to 
19 "Any telephone can be considered a point of purchase location since it is possible to 
telephone... and place a credit card order over the phone. 

Accordingly, the skilled person aware of both Adam 710 and Campisano '447 
would understand that the customer ID sent to the server in Adam 710 could be the 
customer's home phone number, as taught in Campisano '447. However, there is 
nothing in the combined art which would lead the skilled person to consider changing 
the teaching of Adam 710 of a server storing financial data associated with a customer 
identity, the server being arranged to receive from a point of service device a customer 
ID (which, according to Campisano '447, could be a customer home phone number), a 
merchant ID and transaction details and to use these to verify and authorize the 
transaction, to add the features of claim 1 of the server also storing mobile device 
identity information and responding to receiving both a first part of authorisation data 
and mobile device identity data. 

Thus, even if Adam 710 is read in view of Campisano '447, this would not teach 
the skilled person the feature of a server "adapted to store said mobile device identity 
information and said authorisation data including a second part of the authorisation data 
comprising financial data relating to a user of the mobile device" and "in response to 
receiving said first part of the authorisation data and the mobile device identity data " 
proceeding to "verify said authorisation data and to retrieve said second part of the 
authorisation data comprising the user's financial data to complete a transaction" 
according to claim 14. 

The Examiner suggests, without articulated reasoning that "it would have been 
obvious to one of ordinary skill in the art at the time of the invention to expand the 
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apparatus of Berardi et al to include the CSC to administer accounts of merchants and 
customers as taught by Adam et al. and cross-linking of a card holders phone number 
to the credit card number and providing the customer with a corresponding PIN". 
However, as explained above, even if one of ordinary skill in the art were to do this the 
combination would only allow them to use a card holders home phone number as a 
customer identifier, as taught by Campisano. There is nothing in the combined teaching 
to lead one of ordinary skill in the art to the features of a server storing or responding to 
a first part of authorisation data and mobile device identity information according to 
claim 14. 

Accordingly, applicant urges that claim 14 is not obvious over Berardi '226, Adam 
710 and Campisano '447. Accordingly, it is respectfully submitted that claim 14 is 
allowable and should be allowed, along with its proper directly dependent claims 16-23 
and 25, as well as indirectly dependent claim 24. 

Berardi '226, Adam '710, Campisano '447 and Grunbok '603 

The examiner suggests that Berardi teaches the features of claim 26 with the 
exception of the features "at least one server device for providing data and/or processes 
to support a transaction using the at least one client device, said transaction comprising 
a transfer of funds between financial accounts and including verification of authorisation 
data"; "update means for updating data representing a cash amount"; "the at least one 
server device is adapted to store said identity information for said mobile device and 
said authorisation data including a second part of the authorisation data comprising 
financial data relating to a user of the mobile device and, in response to receiving said 
first part of the authorisation data and said identity information for said mobile device, to 
verify said authorisation data and to retrieve said second part of the authorisation data 
comprising the user's financial data to support a transaction"; and "transaction 
comprising a transfer of funds at least in part by updating the data representing a cash 
amount". 

Again, this objection appears to be an improper "mosaic" type argument that the 
different features of the claim can be separately found in different ones of a plurality of 
documents, in this case that different features of claim 26 can be separately found in 
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four different documents. It is respectfully submitted that the mere identification of 
separate disclosures of the different features of the claim in different documents does 
not show that "the subject matter as a whole would have been obvious" unless it can be 
explained why the skilled person would be motivated in an obvious manner to select the 
different features of the claim from the different documents and then to combine them to 
arrive at the subject matter of the claim. 

Further, the Examiner's analysis of the prior art is not accepted by the Applicant. 
In particular, applicant rejects the assertion that the feature of "the at least one server 
device is adapted to store said identity information for said mobile device and said 
authorisation data including a second part of the authorisation data comprising financial 
data relating to a user of the mobile device and, in response to receiving said first part 
of the authorisation data and said identify information for the mobile device, to verify 
said authorisation data and to retrieve said second part of the authorisation data 
comprising the user's financial data to support a transaction", is taught by Adam 710 in 
view of Campisano '447. 

This feature essentially corresponds to the feature of claim 14 "the at least one 
server device is adapted to store said mobile device identity information and said 
authorisation data including a second part of the authorisation data comprising financial 
data relating to a user of the mobile device and, in response to receiving said first part 
of the authorisation data and the mobile device identity information, to verify said 
authorisation data and to retrieve said second part of the authorisation data comprising 
the user's financial data to complete a transaction" which was discussed above. 

The only substantive difference between these features is that claim 14 refers to 
financial data to "complete" a transaction whereas claim 26 refers to financial data to 
"support" a transaction. Otherwise the differences are merely minor matters of 
nomenclature such as using "mobile device identity information" in place of "identity 
information for said mobile device". 

Applicant respectfully asserts that these differences in wording are not relevant to 
the arguments regarding obviousness of this feature set out above. Further, it is 
submitted that even according to the arguments in the Office Action the teaching of the 
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further cited document Grunbok '603 relates only to stored data representing a cash 
amount and is not relevant to obviousness of the identified feature. 

Accordingly, it is submitted that for corresponding reasons to those set out above 
for claim 14, this feature of claim 26 cannot be arrived at by combining the teaching of 
Berardi '226, Adam 710, Campisano '447 and Grunbok '603. Accordingly, it is 
respectfully submitted that claim 26 is not obvious, that claims 27 and 28 allowable as 
proper directly dependent claims and that dependent claims 29 and 30 are not obvious 
because they depend from an allowable proper dependent claim. 

Adam '710 and Nguyen '361 

The Examiner rejects claims 31-33 as obvious over Adam '710 in view of Nguyen 
'361 . As explained above, amended claim 31 comprises the features of previous claims 
31 and 33 combined. 

The Examiner suggests that Adam '710 teaches the features of claim 31 with the 
exception of the features "a data store for storing network addresses" and "the data 
store stores network addresses in association with transaction identifiers such that each 
generated receipt can be transmitted to a network address associated with the 
transaction giving rise to the generated receipt". The Examiner argues that these 
features, and the features of claim 33, are disclosed by Adam '710 in view of Nguyen 
'361 . In particular, the Examiner argues that the features of claim 33 are disclosed by 
Nguyen '361. 

It is respectfully submitted that this analysis is incorrect. It is submitted that contrary to 
the analysis set out in Section 20 of the Office Action, Nguyen does not disclose the 
feature that "the data store is adapted to store one or more sets of user-specific data for 
use in authorising transactions", previously found in claim 33. 

As stated in the Office Action, paragraph [0018] of Nguyen '361 discloses 
"transaction data that needs to be delivered... a) a specific destination mobile address; 
b) the type of delivery service... a list of service attributes including, but not limited to, 
the mobile device address and the type of service delivery". However, applicant asserts 
that the teaching of Nguyen '361 is only that this transaction data is to deliver 



26 



Response to Office Action of: 06/09/2009 
Response Dated: 11/09/2009 
Title: Mobile Payments System 



App. No.: 10/553,360 
Inventor: Davies et al. 
Examiner: Monfeldt, Sarah M. 



information regarding the outcome of a transaction which has been completed to a 
mobile device, see for example Nguyen paragraph [0016] "The bank 
server... determines whether the transaction is authorized or rejected, and a 
corresponding response on the outcome of the transaction is sent back to the 
transaction initiator". The paragraph [0018] of Nguyen referred to by the examiner 
relates only the storing of data relating to the delivery of such responses on the 
outcome of transactions and does not relate in any way to data for use in authorising 
transactions according to the feature of amended claim 33. 

Thus, contrary to the Examiner's position, this feature of amended claim 31 
cannot be arrived at by combining the teaching of Adam 710 and Nguyen '361 . 
Accordingly, it is respectfully submitted that claim 31 is not obvious. It is submitted that 
dependent claim 32 is not obvious because it depends from a claim that is not obvious. 



The Examiner suggests that Grunbok '603 discloses all features of claim 34 
except for the feature of "a data store for storing user specific data in association with at 
least one of said identifiers", and further suggests that this feature is disclosed by 
Nguyen '361. 

Applicant respectfully submits that this analysis is incorrect. Applicant asserts 
that Grunbok '603 does not disclose the feature of "a price list processor for processing 
a price list arising from a transaction... the price list processor is adapted to process a 
price list arising from a transaction by applying user specific data," as Grunbok '603 
teaches only methods of arranging payment of a transaction. There is no disclosure in 
Grunbok '603 of processing a price list arising from a transaction by applying user 
specific data. The cited text of Grunbok '603 at column 6, lines 20-31 , teaches only how 
the cost of a purchase can be met by taking funds from a plurality of different user 
accounts. There is no teaching whatsoever that a price list of a transaction can be 
processed in any way, and certainly no teaching that the price list arising from a 
transaction can be processed by applying user specific data according to the feature of 
claim 34. 



Grunbok '603 and Nguyen '361 
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An example of processing of a price list of a transaction by applying user specific 
data is for a loyalty scheme in which a user may have a discount arising from their 
purchasing history, as explained at page 5, line 31 , to page 6, line 2, of the application 
as originally filed. However, it is stressed that this is merely an example and that 
Grunbok '603 does not teach or suggest that a price list of a transaction can be 
processed in any way by applying user specific data. 

This feature is also not taught by Nguyen '361 . Although Nguyen '361 teaches a 
data store there is nothing in the specification to teach or suggest in any way that the 
price list arising from a transaction can be processed by applying user specific data. 

Accordingly, applicant asserts that claim 34 is allowable over this combination of 
references, and that claim 35 is also allowable as a proper dependent claim. 

Berardi '226, Adam '710 and Nguyen '361 

The Examiner accepts that the feature of claim 37 of "transmitting the generated 
receipt to a communication device having a different address in a public network" is not 
taught by Berardi '226, but the Examiner suggests that this feature is taught by Nguyen 
'361 , particularly at paragraph [0018], which refers to a "temporary mobile address". 

Applicant respectfully submits that there is nothing in any of these cited 
references that teaches the feature of "transmitting the generated receipt to a 
communication device having a different address in a public network", as required in 
claim 37. In particular, it is submitted that there is nothing in Nguyen '361 to suggest in 
any way that the "temporary mobile address" corresponds to "a communication device 
having a different address in a public network" to the "address in the public network of 
the communication device identified in the received transaction information" according 
to claim 37. 

At paragraph [0018], Nguyen '361 teaches that the "temporary mobile device 
address... temporarily overrides the pre-registered mobile device address". This will 
cause the "response on the outcome of the transaction" according to paragraph [0016] 
to be sent to the temporary mobile device address and not to the pre-registered mobile 
device address. However, it does not follow from this that the response will be sent to "a 
communication device having a different address in a public network" as required in 
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claim 37, because there is nothing in Nguyen '361 to teach or suggest in any way that 
the transaction is based on received transaction information identifying the pre- 
registered mobile device address. 

While the benefit of hindsight might suggest that the temporary mobile device 
address feature of Nguyen '361 could be used to send a response to a communication 
device having a different address, there is no express teaching in Nguyen '361 to 
suggest that this should or could be done. 

Accordingly, it is respectfully submitted that claim 37 is allowable over this 
combination of references. 

Examiner Response to Arguments 
Regarding the Response to Arguments, applicant submits that the arguments 
above are based on the wording of the amended claims and do not rely on reading 
limitations from the specification into the claims. 



Respectfully submitted, 



Date: 11/09/2009 



By: /Stephen L Grant/ 



Stephen L. Grant 
Attorney for Applicants 
Registration No. 33,390 
Standley Law Group LLP 
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